Simple non-autonomous peering environment watermarking, authentication and binding

ABSTRACT

A Secure Non-autonomous Peering (SNAP) system includes a hierarchical digital watermarking scheme, a central licensing authority, licensed fabricators and assemblers.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/369,708, entitled “SIMPLE NON-AUTONOMOUS PEERING ENVIRONMENTWATERMARKING, AUTHENTICATION AND BINDING,” by Aaron Marking and KennethGoeller, filed Feb. 11, 2009, which application is hereby incorporatedby reference herein and claims benefit of the following U.S. ProvisionalPatent Applications:

U.S. Provisional Patent Application No. 61/148,295, entitled “SIMPLENON-AUTONOMOUS PEERING BINDING,” by Aaron Marking, filed Jan. 29, 2009,which application is hereby incorporated by reference herein;

U.S. Provisional Patent Application No. 61/096,686, entitled “METHOD OFAUTHENTICATING NON-VOLATILE STORAGE MEDIA USING BAD BLOCKS IDENTIFIEDDURING THE POST-MANUFACTURE TESTING PROCESS,” by Aaron Marking, filedSep. 12, 2008, which application is hereby incorporated by referenceherein;

U.S. Provisional Patent Application No. 61/082,404, entitled “SIMPLENON-AUTONOMOUS PEERING,” by Aaron Marking, filed Jul. 21, 2008, whichapplication is hereby incorporated by reference herein; and

U.S. Provisional Patent Application No. 61/027,757, entitled “ENHANCEDWATERMARK PATTERNS IN A SNAP ENVIRONMENT,” by Aaron Marking, filed Feb.11, 2008, which application is hereby incorporated by reference herein.

BACKGROUND

The use of peering networks to transfer media files from user to userhas many attractive features including speed of access for a requestinguser, balancing of bandwidth across the network, and reduction ofbandwidth needed at a central content repository.

However, users freely exchanging content may violate the content owner'sproperty rights.

Content owners also want to restrict the copying of copyright protectedcontent. There are many examples of technologies that make the transferof copyright protected content very difficult. When physical media isused to store content, permanently or temporarily, (for example inelectronic sell though and rental business models), content owners ortheir licensees use a variety of cryptographic binding methods. Thesemethods typically use a media ID in a cryptographic function to protectthe content from being copied or transferred.

Examples of a non-autonomous peering system can be found in U.S. Pat.No. 7,165,050, and US Patent Publication No. 20060064386, both titled,“Media on Demand Via Peering.”

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention may be best understood by reading thedisclosure with reference to the drawings, wherein:

FIG. 1 shows an example of a media file having multiple instances ofglobally watermarked versions.

FIG. 2 shows an example of a media file being parsed into segments.

FIG. 3 shows an example of a data structure for a title schema.

FIG. 4 shows an example of a first order expression of a unique instancepattern.

FIG. 5 shows an example of a first order expression for three uniqueinstance patterns having different global watermarks.

FIG. 6 shows a detailed view of an example of a first order expression.

FIG. 7 shows an example result of an interleave attack.

FIG. 8 shows an overview of the second order expressions of a uniqueinstance pattern.

FIG. 9 shows an example of a hash table hierarchy.

FIGS. 10 and 11 show a comparison of simple non-autonomous peeringpattern expressions and decryption path-based forensic identificationmethods.

FIG. 12 shows an overview of a licensing and authentication system formanufacture and assembly of components of a simple non-autonomouspeering compliance process.

FIG. 13 shows an example of a method of binding a unique chip identifierto the physical defects of that chip.

FIG. 14 shows an example of a method of creating a unique controlleridentifier for memory controllers.

FIG. 15 shows an example of a method to bind a unique controller with aunique set of memory chips.

FIG. 16 shows an example of a method of writing a media file to a memorydevice that complies with simple non-autonomous peering.

FIG. 17 shows an example of a method to validate a media file in amemory device.

FIG. 18 shows an example of a transaction between a host devicerequesting download of content under control of the SNAP licensingauthority.

FIG. 19 shows an example of a host device requesting to decryptdownloaded content.

FIG. 20 shows an example of a host device authenticating content onmemory device.

FIG. 21 shows an example of a host device playing content from a memorydevice.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Using a simple, non-autonomous peering system (SNAP) in accordance withthe description here may provide the advantages of a peering networkwhile preventing the abuse of rights. The SNAP environment or systemcreates unique instances of a particular media file and allows users to‘build’ that instance from other peers according to a well-definedmethodology with several layers of protection. This enables a widevariety of content monetization models, including rental, sell-through,pay per view, theater exhibition and electronic sell through to variousmedia types including but not limited to NAND flash memory, opticalmedia, solid state hard drives, spindle hard drives, etc. Thesefunctions may be provided to consumers via secure ‘swarming’ where afile is provided in segments from various peers in the network or in aclosed network environment or provide secure electronic distribution forpoints-of-sale, such as kiosks, etc.

The SNAP system uses the physical defects inherent in NAND flash mediato bind content to NAND flash. These defects in NAND Flash are calledBad Blocks. NAND Flash is a type of non-volatile solid-state memorycontaining 2 distinct physical storage areas: a Data area composed ofpages physically grouped into Blocks, and a “Spare” area for the storageof logical and physical metadata pertaining to the Data area and thedata stored therein. While the configuration of these two areas may varyfrom Fabricator to Fabricator, both areas are present in all NAND Flashchips. NAND Flash chips are programmed on a page-by-page basis anderased in a block-wise manner in an effort to enhance performance.

Due to the inherent manufacturing methods used to make NAND Flashmemory, it is common for NAND Flash chips to contain up to 5.5% defectsat the time of manufacture. This is necessitated in order for chipfabricators to maintain commercially viable production yields. SinceNAND Flash memory is erased on a block-by-block basis, any defectdetected either during a page program cycle, or a block erase cycledictates that the entire block of memory be identified as “Bad” in orderto avoid potential data corruption. Defective blocks are identifiedduring rigorous post-manufacturing testing, by the chip fabricator, byprogramming a specific value (typically 000h) into the block's sparearea. Runtime detected bad blocks are marked with a different value(typically FFFh for 16 bit blocks) to the spare area.

It must be noted that the discussion below uses NAND Flash terminologyand examples. However, the scope of the claims is not restricted to NANDFlash devices. Other memory technologies may have similarcharacteristics to NAND Flash devices and no limitation to NAND Flashdevices is intended, nor should any be implied.

The SNAP system binds the unique media instances to the specific blockaddress where the content is stored. It also uses a digital signature ofthe location where the unique media instances are recorded, or‘programmed’ in NAND flash terminology, to authenticate the Flash Mediaand the recorded content. It also uses a digital signature of thelocation of the bad blocks to authenticate the Flash Media and therecorded content. These signatures are also used to cryptographicallymodify the keys required to encrypt and decrypt the unique mediainstance.

These two digital signatures are the basis for determining theauthenticity of the Flash Media and content and used in various playersand consumer electronics to stop playback or to revoke or to renew saiddevices and content. Since it is extremely unlikely that any usefulnumber of NAND flash devices have the same pattern of bad blocks, theSNAP system makes unauthorized transfer the content from one NAND todevice to another NAND device very difficult. The SNAP system doesenable the content owner to permit the transfer of content from one NANDflash device to another NAND flash device. The transfer can be a move ora copy transaction or both. This can be done per the content owners'business rules and many or may not involve payment for such a transfertransaction. In any case, the SNAP system controls if content istransferred and does so a secure manner.

SNAP may also offer secure forensically identifiable content for us inelectronic theatrical distribution systems as described in the DigitalCinema Initiative. SNAP's high degree of flexibility, security andforensic accountability come at a relatively low cost in terms of playerand distribution network resources.

SNAP Environment and Pre-Processing of Media Instances

FIG. 1 shows an overview of multiple instances of an authored andencoded master media file. The system applies a different globalwatermark to multiple copies of the master 10. The Global watermarks maycontain zero or more bits of payload data. This discussion uses colorsto differentiate between the different watermarked versions, referred tohere as instances. The instances 12, 14 and 16 are each encoded with adifferent watermark, green red and blue, respectively. Each differentglobal watermark is identified internally by a unique global markidentifier. It must be noted that SNAP may employ many different globalwatermarks. Each global mark is applied to different copies of themaster such that no two different global marks are applied to analogousdata ranges within the master, as will be explained later.

In addition to the three different instances of the master, each of thewatermarking techniques may differ from each other. Instead of havingthree different variations of the same watermarking technique, forexample, one could use three different watermarking techniques, or varythe payload within a single watermark carrier.

As an overview, each of these instances of the master are parsed intosome predetermined number of second order segments, as shown in FIG. 2.In an alternative embodiment, it may also be possible to parse the moviedata into segments prior to the application of watermarks. This methodmay be desirable to ensure that the watermark carrier and/or payload maybe successfully encoded/detected within the data of a single segment.The number of second order segments follows a title scheme, discussed inmore detail in FIG. 3. SNAP uses a bottoms-up methodology, using thesecond order segments to build first order segments, and using the firstorder segments to build expressions that will form unique instancepattern (UIP).

The second order segments of FIG. 2 will generally correspond amongsteach others according to a data range. For example, the data ranges fromthe different instances that correspond to any particular second ordersegment will correspond among the colors. For example, the second ordersegments at the left side of the figure such as 20, 22 and 24 willcorrespond to the same data ranges in the red, green and blue instances12, 14 and 16. Similarly, the ending second order segments at the rightside of the figure such as 26, 28 and 30 will correspond to similar orthe same data ranges among the instances. It should be noted that ifwatermarks are applied in the baseband of movie data prior to datacompression, the inclusion if watermarking data will cause analogoussegments to have different file sizes due to the presence of differentwatermark carrier and/or payload bits.

Because the different instances may all have different watermarks, someaccommodation must be made to allow single key encryption systems thatuse data “chaining” such as AES-E CBC or CTR modes to transition betweenthe segments with different watermarks. This may be accomplished with aninitialization vector table 32. The initialization vector table 32 mayrecord the last 128 bit cipher block of each second order segment. Thiswould allow the single key encryption systems to identify the startingpoint for the transitions.

In CBC mode, for example, each block of cipher text is chained forwardto be used in the decryption of the next block. Since SNAP segmentscontaining different watermarks are concatenated or otherwise joinedtogether to form a media instance, normal CBC mode would fail as thewatermarking process itself would change chained blocks. By injectingthe appropriate 128 bit watermarked cipher text bock in a manner similarto initialization vectors used to start a CBC chain.

As mentioned above, the second order segments are concatenated orotherwise joined together to form the first order segments. The firstorder segments are then concatenated to form Global segments, eachexpressing one element of the Unique Instance Pattern. The Globalsegments are then combined together to form a media instance. When auser requests a media file to be transferred, the system accesses thesegments according to a title schema mentioned before. The segments maycome from many different sources, including a central file server, otherusers on the same network, such as on a DVR network, a cable set top boxnetwork, or via direct transfer from a kiosk, etc.

An example of such a title schema is shown in FIG. 3. As mentionedabove, the title schema uses a bottoms up methodology. In the exampletitle schema used here, the instances 12, 14 and 16 are segmented into2000 second order segments such as 40. In order to form a first ordersegment such as 42, 20 second order segments are concatenated togetherfrom the appropriate second order segments, in this case 100 first ordersegments are formed. The title schema determines which combination ofwhich second order segments are taken from which instance. In theexample given here, the first order segment S1 is formed of second ordersegments S1-S20, and the first order segment S100 is formed of secondorder segments S1981-S2000.

The formation of the global segments such as 44 results from theconcatenation of the first order segments. In the example schemaprovided, the concatenation of 20 first order segments results in oneglobal segment. The global segment GS1 44 in this example is formed by aconcatenation of first order segments S1-S20. The term segment refers tothe data range of the first or second order segment, while the term‘expression’ refers to the ordering and substance of the segment as tothe type and watermark of the segments that make up the first order andglobal segments.

It must be noted that the particular numbers given here for the numberof second order segments, first order segments, global segments, etc.,are merely examples and specifics are provided only as a means foreasing understanding of the invention. Similarly, while the segments arejoined here using concatenation, other types of joining the lower ordersegments together to form high order segments may also apply.

Returning to FIG. 3, one of the global segments such as 44 willcorrespond to one of the elements used in the unique instance pattern(UIP). It is the UIP 48 made up of elements such as 46 that the userwill see as the media file desired to be downloaded or transferred. Thismay be better understood with reference to FIG. 4.

Within each element of the UIP, is a first order expression of the UIP.This creates a hierarchical watermarking framework. As can be seen inFIG. 4, the UIP in this example may be referred to agreen-blue-red-blue-green UIP. This pattern is repeated at the firstorder segments. The first order segments S1-S20 that make up the element46 have repeated inside the same pattern at segments 50, 52, 54, 56 and58.

In the particular example given here, the UIP isGreen-Blue-Red-Blue-Green. The pattern then repeats within the greenfirst order expression E1, such that the element 50 is green, element 52is blue, element 54 is red, element 56 is blue and element 58 is green.This pattern would then repeat in each of the first order expressions.

FIG. 5 shows first order expressions within the global expression rangeof the first element 46 for three different UIPs having different globalsegments for the first element and identical elements for the remaining4 elements. This highlights the unique elements mappings for eachdifferent element within the expression ranges of the first element.

The element 60, when expanded, repeats the green-blue-red-blue-greenpattern within its first order segments shown by 62. The element 64,when expanded, repeats the red-blue-red-blue-green UIP shown by 66.Further, the element 68, repeats the blue-blue-red-blue-green patternshown by 70.

FIG. 6 shows a more detailed view of the first order expressions. Thefirst part of the expression, A, is a first order offset. The firstorder offset is the number of first order segments from the start of theglobal expression data range before the expression groups D at the endof the expression. In this example, the offset is 3.

The part of the expression B is the first order expression groups 1-5.As used here, the term ‘expression group’ is a set of a number ofsegments, such as first order segments. In this example, there are threeinstances, and the UIP contains 5 elements, so there will be 5expression groups each containing 3 first order segments.

After the first order offset, there is a region C of the expression thatcomprises the first order expression group offset. SNAP uses a mappingto the global watermarks of the parent UIP element within which thefirst order expression takes place to determine the first orderexpression group offset. For example, these offsets may be set byconvention in which if the parent element contains the green watermark,the first order expression group offset would be 0. If the parentelement contains the red watermark the offset would be one, and if theelement contains the blue watermark the offset would be two. Thismapping may vary among the five elements, although it may also be thesame for all five elements.

The region D of the first order expression is referred to as the firstorder tail. This tail provides forensic reinforcement of the UIP in theevent of splicing attacks. The element of FIG. 6 is a green watermarkedelement, so the tail D is green. As will be discussed in more detaillater, this acts a check on the native watermark of the expression inthe case of a splicing attack where different portions of the expressionare in the clear and spliced together.

For example, assume that two media instances are sampled and thenspliced together at a fine granularity. The first media instance wouldconsist of first order segments 1-20 from a media instance having agreen-blue-red-blue-green instance. The second instance would consist ofsegments 1-20 from a media instance with a UIP ofred-green-green-green-blue. When these instances are spliced together,the tail would show both red and green watermarks, indicating that theywere spliced and not legitimate expression groups.

This first order level of marking shown in FIG. 6 provides one means ofidentifying the global patterns of colluding files in the case ofinterleaving carried out cress an entire global segment. It couldpotentially be vulnerable to splicing at the first order segment level.SNAP uses a second order expression of the UIP within selected firstorder segments. That is, when the second order segments are combinedtogether to form the first order segment, second order segments of theother global instances are combined in the pattern of the UIP, at leastin part.

For example, using the green-blue-red-blue-green UIP discussed above,the first order segments would be combined into expressions that mimicthis UIP. In addition, inside the first order segments, the second ordersegments would also mimic represent this pattern. In order to mount acollusion attack such as the splicing mentioned above, the pirate wouldneed the ability to identify the granularity of the watermarkedpatterns. However, SNAP does not rely upon a player's ability to detector read forensic watermarks, instead using encrypted composite hashtables to identify differently marked data, an attacker's ability todetect and read all marks is highly unlikely.

FIG. 7 shows an example of a portion of a media instance wherealternating data was sampled from two source files then recombined in aneffort to obliterate watermark patterns and gain access to the mediainstance. The first order segment 80 is the first element consisting ofa data range of first order segments 1-20 from a media instance havingthe UIP green-blue-red-blue-green as discussed above. The first ordersegment 82 is the first element consisting of a data range of firstorder segments 1-20 from a media instance having the UIP ofred-green-green-green-blue.

The first order segment 84 is a ‘colluded’ version of the above firstorders segments 1-20 interleaved frame by frame in an attempt toobliterate the watermarks. If it were in color it would be ofalternating red and green ‘stripes’ of data. The segments are jumbledand would be unworkable as an actual first element of a UIP. One of thepowerful aspects of SNAP, however, is not only its ability to cause suchan attack to ultimately fail because the segments will be unusablewithin the title schema to decrypt the media instance, but also canallow identification of the source of the two spliced files in the eventthat movie data had been “ripped to the clear”.

An analysis of the offset region O of the element 84 shows that the redand green watermarks are present, meaning that the colluding files are 1element E1 from a red watermarked file and 1 element E1 from a greenwatermarked file. Further analysis of the offsets will show that thereare only two colluding files in this instance, a file with a UIP thatbegins with red and another that begins with green. Analysis of theportions 2-5 results in identifying the UIP that begins with red to be aUIP of red-green-green-green-blue and the UIP that begins with green isa green-blue-red-blue-green UIP. The tail section T confirms thisanalysis.

As can be seen from above, the SNAP environment and schema allows notonly disabling of the use of the file, but identification of the sourceof colluded files for forensic tracking of the media instances in thesystem. This was accomplished using first order expressions of theelements of the UIP. The methodology employed to determine theexpressions of second order segments within the first order segmentsallows for even more granularity.

FIG. 8 shows an overview of the second order expressions of the UIP.These offer protection for intermediate granularity attacks wherecomplete first order segments from multiple media instances would bespliced together in an attempt to obliterate a first order watermarkingpattern. Second order expressions are normally bounded by individualfirst order segments to maintain network efficiency for swarmingdistribution. This is not intended as a limitation, and it is possiblefor the second order expressions to span first order segment boundariesin the manner of global expressions. Typically, there will be one firstorder segment containing a second order expression of the UIP within afirst order expression group. As mentioned above, it is desirable torandomize the pattern offset from expression group to expression group.

In the example of FIG. 8, first order segments will be selected for thesecond order expression group using an incrementing form of theexpression group offset such that they may occur at multiple offsetsthroughout the first order expression groups. Internally, the firstorder expression groups use a second order expression group offset. Thesecond order expression group offset is mapped to the different globalwatermarks of each element on an element by element basis throughout theUIP.

FIG. 8 shows the first order segments 1-20 from the example file havingthe global UIP 48 of green-blue-red-blue-green. Each second ordersegment expression, which is a concatenation of 20 second ordersegments, mimics the UIP of green-blue-red-blue-green within it in theelement values E1-E5, after the initial offset portion and the trailingtail portion. Second order expression group 90 corresponds to the firstsegment 92 of the first order expression group, and second orderexpression group 94 corresponds to the ninth segment 96 of the firstorder expression group. The determination of the first order expressiongroups consisting of which second order expression groups is driven bythe title schema and the offsets that are set by convention.

SNAP Hash Tables

One of the elements that allows the SNAP environment to create andmaintain the watermarks is the hash tables. The hash tables are used tomanipulate the behavior of swarming applications such that they selectappropriate data from peers, driven by the title schema, without theapplication being able to detect or interpret SNAP's forensic watermarksor the media instance patterns.

In addition, SNAP generally employs CMAC (cipher-based messageauthentication code) tags. These tags, when received, are compared to agenerated tag from the message using a key that is cryptographicallybound to the physical attributes of the storage media it is delivered toin order to ensure they match. These tags are renewable. When thewatermarked and encrypted data is hashed with a new CMAC key a completerenewal of descriptor metadata occurs. This does not invalidate moviespreviously delivered, but disallows the exchange of keys and/ordescriptor metadata among users as in the case of a key sharing attack.CMAC tags also provide authentication of the data and error correction.

The CMAC tags of every segment within a unique media instance arecontained in the composite hash table for the media instance. It isreferred to as a composite hash table because, like the watermarking,the hash table generation employs a bottoms up methodology as shown inFIG. 9.

FIG. 9 shows an overview of a hash table hierarchy for one mediainstance corresponding to one watermarking method. In this example, themedia instance is the blue watermarked instance. The process begins withthe second order segments. The second order keys are batch calculated byfirst hashing plaintext second order segments using the renewable titlecrypto CMAC keys. Each segment's CMAC tag is then combined with ananalogous tag from a master key second order hash table (HT²) such as100 using a non-reversible combine function. Master key second orderhash tables are analogous to first order key has tables in structure,but populated with unique random values. One set of master key secondorder hash tables may be used for all media instances.

As mentioned above, one advantage of using CMAC rather than the morecommon SHA-1 or MD5 plain hashing is that CMAC allows SNAP to quicklyrenew a title's keyset by changing the title crypto CMAC key andrepeating the key generation process. The process may even occur after atitle has been released into the network without requiring re-mastering.

The CMAC tags for each group of second order segments that comprise afirst order segment are written into a first order key hash table suchas 102. Each CMAC tag is then combined with its corresponding randomhash analog from the first order segment master key has table such thatthe resultant value may be used as a unique segment key. SNAP thenencrypts each second order segment to its corresponding key.

It is desirable that all hashes and random values are verified as uniqueafter each state of pre-processing to ensure that no data exhibiting ahash collision is published. A hash collision occurs when two differentsegments have matching hashes. If this occurs, one of the instances musthave it data modified in a non-user perceptible manner such that itreturns a unique hash. This ensures that the tags can serve as uniqueidentifiers for the segments they describe and to protect againstattackers being able to use hashing collisions to reverse engineerhashing algorithm behavior and subsequently discover encryption keygeneration methods.

As an added protection, the first order key hash tables such as 102 arecross mapped. Cross mapping involves using a CMAC tag for an analogoussecond order segment from another watermarked media instance to generatethe second order segment. For example, a key for a blue second ordersegment would be generated using the hash of the analogous red secondorder segment. Red second order segment keys would be generated withhashes of the green second order segments, and green second ordersegments would derive their keys from the blue second order segments. Inthis manner, keys are derived in a manner using information that anyindividual media player will not possess.

After encryption of the second order segments, they are concatenatedtogether to create first order segments. The resulting first ordersegments are hashed using the same CMAC used to write the second orderhash tables. The CMAC tags are then written to the first order hashtables. The second order hash tables previously created may be nestedunder their respective first order segments CMAC tag in the first orderhash table (HT¹) 104.

The first order hash tables such as 104 are then combined to create theblue global hash table 106. The blue global hash table then contains allof the necessary information to describe any blue first and second ordersegments in order to reconstitute a media instance using bluewatermarked segments. When used in conjunction with the red and greenglobal hash tables, a media instance using multiple global watermarksmay be decrypted.

FIGS. 10 and 11 show a comparison of SNAP's pattern expressions anddecryption path and patterns generated by a sequence key based (SKB)system. FIG. 10 shows a forensic pattern based upon the SKB system.Using a device key at a device such as a media player 110, a media keybundle 112 and the sequence key bundle 114, the variants of enhancedvideo objects (EVOBs) are placed into a patterned resulting audio videostream 116.

While the resultant complexity would appear on its face to protect themedia instance, far more critical is the pattern leakage. EVOBs arediscrete files that directly represent the boundaries of the forensicwatermarking pattern. This provides hackers with pattern informationthat could allow them to spoof the forensic patterns. This in turncomprises the ability to forensically detect the decryption player.

In contrast, the media instance 120 shown in FIG. 11 is represented onlyin part by the encrypted composite hash table 122. The actual resultingmedia stream 126 is a result of further encryption at two further levelsas discussed in detail above, requiring the unique encrypted compositekey bundle 124. In this manner, the multi-level watermarking and use ofthe UIP throughout the levels of the media instance, as well as the hashtable generation and compositing, the SNAP environment provides a secureauthentication environment for media instances that are not only havehigher levels of hacker protection, but also have forensic capabilitiesto detect decrypting players.

One aspect of the SNAP environment that has been mentioned above is theseparation of the decryption and the keys from any particular mediaplayer. In a typical secure environment, the requesting player receivesthe key and/or hash tables that then allow the player to decrypt thedesired media stream. In the SNAP environment, the decryption capabilityis player independent and thereby makes it both more robust and moreresistant to having keys reside at any particular device.

However as mentioned previously, when content is stored on physicalmedia it is important to bind the content and keys to the media suchthat it cannot be transferred without authorization. Both the SNAPencrypted unique media instances and the separate keys need to becryptographically bound to the media to prevent unauthorized transferfrom one NAND flash device to another NAND flash device. This isdiscussed in more detail below in the SNAP Secure Host Environment.

SNAP Secure Host Environment

The SNAP secure host environment has a SNAP Renewable Logic, code thatresides in a secure processor on the player host or in the NAND flashcard controller or in both. The SNAP Renewable Logic contains data andtemplates for generating specific cryptographic data. A SNAP RenewableLogic is an intermediary that provides a known cryptographic environmentfor communication and cryptographic calculations between its hostapplication and SNAP enabled NAND Flash devices.

SNAP Renewable Logic transforms cryptographic data differently for eachNAND flash device. The inputs to the SNAP Renewable Logic include: 1)device bad blocks, chip ids, SNAP chain logs, SNAP segment chains and 2)a SNAP renewal string. The outputs of the SNAP Renewable Logic are aSNAP HAK (hardware authentication key), which is used to authenticateand cryptographically protect the SNAP HAN (hardware authenticationnumber). The SNAP Renewable Logic performs differently on each NANDflash device because the input variables listed in 1) above vary fromNAND flash device to NAND flash device.

This provides a greater level of complexity for an attacker because itis unlikely that any two NAND flash devices use the same authenticationand cryptography in an identical manner. The SNAP renewal string changesthe logic, both the algorithm and the variables used in SNAP processing.This SNAP renewal string can be updated on a periodic basis to enable aStudio to change the manner in which unique media instances and therespective keys are cryptographically bound to the defects of a NANDflash device.

Authenticating Non-Volatile Storage Media

In one embodiment, the trust transaction may be performed using therandom nature of bad blocks on the non-volatile storage media.Generally, manufacturers of flash and other storage media use a methodof bad block identification that allows the device to identify badblocks of physical memory following manufacture. By doing so, themanufacturer can still sell the device and it will operate as intended,as the bad blocks are marked and identified for any processing devicethat accesses the remaining ‘good’ blocks of memory.

During post manufacture testing, each block of physical memory undergoesmultiple ‘program,’ ‘read’ and ‘erase’ operations. When any or all ofthe pages that make up a memory block fails, the entire block is markedbad by writing a specific value (e.g. ‘ooh’) in pages of the bad block,as well as within the Spare Area related to the block. These bad blocksdetected at manufacture are differentiated from the bad blocks detectedduring subsequent consumer operation of the device. Bad blocksidentified during consumer operation are identified by writing adifferent value (e.g. ‘Foh’) in the pages and spare area of the block-.

Since the pattern of bad blocks identified at the time of manufacturingis random, this information provides a unique value usable to provide aunique authentication and cryptography mechanism. The pattern of badblocks may be combined with the unique media ID of the device to createa unique authentication value. It may also be possible to identify aspecific page which has failed within a block of memory, the value ofwhich may also be usable to enhance the robustness of thisauthentication. This would allow for a unique authentication value atmanufacture, but some sort of infrastructure may be helpful to ensurethat this unique value is monitored and tracked to prevent it from beingforged or otherwise copied.

The manufacture of these devices may be performed under a centrallicensing authority, where the licensing authority ensures that devicesare ‘SNAP compliant.’ An overview of such a system is shown in FIG. 12.In FIG. 12, the SNAP Licensing Authority, or SLA, 150 has secureconnections through portals available at the various points in themanufacturing chain. These portals such as 160, 170 and 180, provide asecure and authenticated link to the SLA. This increases the difficultythat a rogue fabricator/pirate would have in trying to hack or otherwisesubvert the information exchanged between these two entities.

Typically, the manufacturing chain would have at least three portions.The SNAP portal 160 resides at a chip manufacturer that produces NANDFlash memory chips. The use of the term chip with respect to NAND Flashmemory shall be considered to broadly cover any NAND Flash memory array(die) whether it is in the form of a discreet IC packaged commoditymemory chip, or integrated into another device, as in the case of aMulti Chip Package (MCP), or Solution on a Chip (SoC). Multi-planardevices containing multiple planes of either SLC or MLC NAND Flash shallhave their planes treated in a manner that is consistent with theirmemory addressing behavior (single or multi-device addressing).

The SNAP portal 170 resides at a memory controller manufacturingfacility. Most non-volatile memory products have an on-board controllerto manage the movement of data into and out of the various memorystructures on the product. In the discussion here, this controller willbe manufactured according to the SNAP protocols and may be referred toas the SNAP compliant

The SNAP portal 180 resides at an assembler that combines a controllerwith a set of memory devices into a consumer product, such as a memoryproduct (SD card, Flash thumb drive, etc., a digital media contentplayer, such as a MP3 player, a video game player with movie or musiccapabilities, or any other product that uses non-volatile memory tostore digital content. For purposes of this discussion, each entity willbe discussed as though they were separate entities, with theunderstanding that they may occur in any combination of entities or allat one place. Compartmentalization may be preferable, as it adds anadditional layer of security. Each entity requires a license. Memoryfabricators will have a chip binding license, controller fabricatorswill have a controller binding license and assemblers will have achipset binding license. If one entity were performing all threefunctions, that entity would have all three licenses, increasing therisk of breach.

FIG. 13 shows an example of a method to generate and imprint a uniquechip identifier (ID) onto the memory chips. The term ‘chip’ as used herean in the claims refers to any individualized portion of memory.

In the diagram, the blocks to the left side of the figure are performedat the fabricator and the blocks to the right side are performed at theSLA. The process begins at 190 when the fabricator tests a completedmemory chip and determines its bad blocks, as discussed above. The badblock data is received at 192 at the SLA. The SLA then assigns a uniquechip ID to the chip at 194 and decrypts the bad block data at 196. Ifthe memory is being programmed one chip at a time, the Fabricator may bea memory manufacturer. Alternatively, when memory chips are beinggrouped together, the Fabricator may be an assembler as well, as isdiscussed in more detail below with regard to the controller and chipset programming.

The SLA then performs at least one operation on the bad block data,either alone or in combination with the chip ID, to produce a uniqueidentifier for the chip. The chip ID is then signed by the SLA using avendor-specific CMAC key for that fabricator at 200. The signing processmay employ a public key such that it may be authenticated by devicesother than the SLA, or it may employ a secret key only such that onlythe SLA may authenticate it. The resulting CMAC digest is referred toherein as a Chip CMAC.

Using the chip's private key, the SLA then encrypts the chip ID and issignature tag to create a Hardware Authentication Number (HAN) at 204.The SLA then signs the chip ID and HAN at 206 and encrypts them. Theencrypted HAN and ID are then sent to the SNAP portal at the fabricatorat 208.

Back at the fabricator, the SNAP portal decrypts and validates the HANat 210. Either under control of the SNAP portal, or possibly within theSNAP portal itself, the chip is them programmed with the HAN and chipID. The programming may involve a ‘write once’ strategy, in which a setof gates within the memory (such as NAND gates in a NAND flash memory)are physically damages so as to be read-only. This adds another layer ofsecurity, as it prevents changing of the chip ID or HAN.

Unlike the SLA-centric chip identifying process, the process forcontrollers is somewhat more involved for the fabricator. An example ofthis process is shown in FIG. 14. At 220, a SNAP controller is connectedto the SNAP portal at the controller fabricator. The SLA or the SNAPportal, or both, establish as session as 222. The SLA then sends thecontroller ID and the firmware to the fabricator at 224. The SLA mayrecord the controller ID into a database or other type of storage,associated with the fabricator, for later monitoring and tracking, at232.

Meanwhile, the fabricator has received the controller ID and thefirmware through the SNAP portal at 226. The SNAP portal, either byitself, or by controlling the fabricator's machinery uploads thefirmware into the controller, making the controller a SNAP controller,at 228. The SNAP controller is then programmed with the controller ID at230.

Having seen how one could assign unique IDs to the memory chips and thememory controllers, the discussion now turns to binding a uniquecontroller with a set of memory chips, referred to as chipset binding.An example of this process is shown in FIG. 15.

At 240 the device that contains both memory chips and a controller isconnected to the SNAP portal for programming. The chips are verified,typically by performing program/verify and erase/verify testing on eachchip to detect counterfeit SNAP compliant chips. This may beaccomplished by having the bad blocks tags erased. If this is detected,the device is rejected as counterfeit. Further testing may includeparsing a chip's spare area to detect the presence of any runtime badblocks. The SNAP portal may also authenticate the chip's HAN accordingto a field parsing of the HAN.

Upon verification of the chips, the SNAP portal reads the controller IDat 244 and sends the controller ID and all HANs to the SLA at 246. TheSLA then computes a different Hardware Authentication Code (HAN) andreturns it to the SNAP portal at 248. The portal then programs the HANto the SNAP controller and each chip using, for example, the write oncestrategy discussed above. As an added measure of security, the SNAPcontroller and the SNAP portal jointly compute an encrypted blockfailure log that contains all bad block addresses for all chips in thechipset, and may write those to each constituent chip's system area forfuture reference. Any use of the device containing this controller andchips in compliance with SNAP will ensure that the chips and thecontroller all have matching HANs to ensure that the device is valid.

Once the SNAP compliant devices manufactured from the above processesbecome available, they can be used to provide media content to users. Anexample of this process is shown in FIG. 16. In FIG. 16, the media filesare acquired. The media files may desirably be those using thewatermarking hierarchy discussed above with regard to FIGS. 1-11. Thewatermarked instance or instances are then written into the memory at262.

The manufacture of the finished products that include the media filesmay be recorded in a database. The database will allow tracking ofcopies of the content and provide the basis for the content providers toreceive license royalties.

Once the files are written to memory, a log may be created, binding thelogical and physical locations of the files in the memory at 266. Thislog can then be used to verify and confirm the authenticity of thememory content upon access. An example of this process is shown in FIG.17.

In FIG. 17, a SNAP compliant device, having watermarked contentcontained in memory chips under the control of a SNAP controller isconnected to a host device. This may be a computer, a set-top box,kiosk, television, media player, portable device, etc. This process mayinvolve an update of either the device or the host device, dependingupon the dates of the update files on either device.

Upon manufacture, the host devices is provided with the most up to dateinformation on watermarking algorithms, as discussed above, as well asthe media key bundles, revocations of licenses, either for users, mediaor devices, etc. Similarly, upon receiving a media instance, a devicereceives the most up to date information at that time. When the deviceand the host device connect, a determination is made as to which has themost up to date information and whichever one does, it provides thatinformation to the other device. In this manner, the most up to dateinformation with regard to licenses, revocations and algorithmspropagates throughout SNAP compliant devices. Host devices may beupdated every time they connect with a new piece of media, either byexternal connection to a device or when a media instance is downloadedthrough a network.

Once the update has completed at 270, the host device acquires the logfile of the files and locations generated upon writing of the mediainstance into the memory at 272. This log file is then decrypted/decodedto authenticate the media file based upon its locations in the memory at274.

Meanwhile the memory controller will perform the same operations on thelog file and the two results are compared at 276. If the two resultsmatch at 278, the playback of the media instance is allowed at 282. Ifthe two results do not match, the device is disabled, or the mediainstance is disabled at 280.

Having established the various components and methods of the SNAPinfrastructure, it is useful to discuss the events occurring as a hostdevice requests and then plays some piece of content, such as a movie,an audio file, etc. These will be discussed in terms of a movie in FIGS.18-21, with the understanding that the content is any type of protectedcontent that is in downloadable form.

In FIG. 18, a host controller requests to download content from the SNAPlicensing authority (SLA) server. This download, as discussed in muchdetail previously, may actually be from peer devices, but under controlof the SLA server. At 290, the controller in the playback devicecontacts the SLA server and requests the content, in this example, amovie.

The server generates a unique instance pattern (UIP) such as thosediscussed in detail above, at 292, and generates the hash tableassociated with the UIP at 296. At 300, the server sends the hash tableto the host controller, and then stores the controller ID of the hostcontroller with the UIP at the server side. This allows foridentification of any instances of the UIP that appear, such as in thecolluded attacks discussed above, and allows tracking of the source ofthe segments being pirated.

At 298, the host controller receives the hash table. At 302, the hostcontroller locates the various segments of the movie, wherever located,to fulfill the requirements of the hash table. Some segments may beobtained from peers, others may be obtained from a content provider,etc. At 306, the host controller generates a segment chain log. Asegment chain log is a log of the locations of all segments of a movieinstance. The segment chain log may be generated by the host controllerupon storage of the movie into an attached flash device, or even in itsown non-volatile memory. A chain log is a sequential log of the physical(chip/block/page) addresses where a specific segment of a movie instanceis stored in a NAND flash chip. Chain log may be associated with adevice, a segment or a complete piece of content, such as a movie.

Having fulfilled the hash table and acquired all the necessary segments,the host controller now will acquire all of the necessary keys to allowaccess to the encrypted segments. This is shown in FIG. 19.

At 310, the host controller contacts the SLA server and requests a keybundle for the UIP that it downloaded. The server looks up the UIP at312 and generates its key bundle at 316. Meanwhile, the host controllersends the chain log generated upon reception of all of the segments at318. The SLA server receives the chain log at 320.

The SLA server instantiates the SNAP Renewable Logic, discussed above,at 324, and initializes it using a renewal string at 326. This ensuresthat the SNAL Renewable Logic ‘refreshes’ the processes used to generatekeys, making them harder to break. At 328, the SLA server uses the chainlog that identifies the locations in the device where the segments arestored to bind the keys to these device attributes. This entire bundleis then encrypted at 330 and returned with the renewal string to thehost device at 334.

The host controller receives the bound key bundle and renewal string at332. As mentioned with regard to FIG. 16, the renewal string may bepassed from one device to another upon connection as part of the mostupdated information with regard to renewals and revocations. At 335, thehost device programs the key bundle, the renewal string and the programsegments to the flash device.

The content now resides on the flash device, ready for access by anappropriate host device. An example of this process is shown in FIG. 20.At 336, the host device establishes a secure session with the flashdevice. The host device instantiates the SNAP Renewable Logic at 338,and requests playback of the movie stored on the flash drive at 340. Theflash device provides the movie's hash table and encrypted key bundle tothe host device at 344.The host controller authenticates the movie'ssegment chain log at 346 to ensure that the copy of the content isvalid. Upon authentication, the host can play the movie.

Playing the movie or other content launches a final process in theauthentication and security structure. An example of this is shown inFIG. 21. The host controller plays the movie by requesting the moviesegments previously downloaded into the flash device at 346. Thesegments are received at 348. These segments may be second ordersegments as discussed in detail above with regard to watermarking.

The hash of the segment is authenticated against the previously providedvalue in the encrypted hash table at 350. The chain log for that segmentis provided at 352 from the flash device, which the controller uses tocompute the key for that segment at 354. Once the key is computer, thehost controller can decrypt the segment at 356 and being rendering thecontent to a user.

In this manner, multiple levels of security, from the watermarking ofthe content to the generation of a unique identifier for the memorychips, the controller and the chipset upon which the content will bestored, protect the content providers from pirating of their content.The transactions discussed here, from the watermarking and loading ofmedia files to the manufacture and binding of product components to themedia files are tracked and recorded, allowing distribution of contentwhile ensuring both protection of rights and the revenues that flow fromthose rights.

Thus, although there has been described to this point a particularembodiment for a method and apparatus for a SNAP environment,watermarking of digital data at multiple levels, and authentication ofcarrying devices, it is not intended that such specific references beconsidered as limitations upon the scope of this invention exceptin-so-far as set forth in the following claims.

What is claimed is:
 1. A method of watermarking a digital file,comprising: digitally watermarking a digital media file using at leasttwo different watermarks, producing at least a first and secondwatermarked files; segmenting the watermarked files into second ordersegments; combining the second order segments into first order segments,such that the first order segments contain a combination of second ordersegments from the first and second watermarked files according to aunique instance pattern; combining the first order segments into globalsegments, such that the global segments contain a combination of firstorder segments from the first and second globally watermarked filesaccording to the unique instance pattern; and generating a unique mediainstance from the global segments, wherein the global segments make upelements of the unique instance pattern for the unique media instance.